Convert to stable ns name - #595

So basically, this freezes the current namespace as Imath_3_2 (by default, can be changed at build time), Imath is the user-facing namespace alias to that, and now the ABI is frozen at 3_2 even for future versions of the Imath library? But if we really needed to in the future, Imath v6.0 might need to bump the ABI, and thus the namespace, but that would be non-interfering?

So basically, this freezes the current namespace as Imath_3_2 (by default, can be changed at build time), Imath is the user-facing namespace alias to that, and now the ABI is frozen at 3_2 even for future versions of the Imath library? But if we really needed to in the future, Imath v6.0 might need to bump the ABI, and thus the namespace, but that would be non-interfering?

That was the thought - I thought about fixing and removing the version number, but that would make it annoying in the future if we want to add changes - instead, we would do like what you've done in oiio (I didn't direct copy because introducing a nested namespace, while cleaner, would change existing behavior). So we would add a new stable name and include it in the outer name (Imath) and off we go.

The next step, which this change does not make, is to remove the per-version SO name, and switch to just a stable SO name to increase the backwards compatibility

Let's discuss this in the next TSC meeting. We talked about the next step being to convert Imath to exclusively header-only, thus eliminating ABI issues altogether.

yep, happy to talk through next TSC - although we still have to get to a stable namespace for users of imath that doesn't change with the versioning of imath (which it does currently), and abi is passed along with the implementation, even if header only, so the header only or not I view as orthogonal. I would also be fine if we change the contract to just having all the objects in the Imath namespace, and no versioning at all but a guarantee we won't ever change or add anything may be an issue, the typenames in downstream users would then be simpler than what is here, but may not be as flexible?

If package A uses Imath types in its public API, and package B uses A's APIs, then those two packages need to be built against the same Imath ABI (though I think that maybe this mostly gets papered over by those templates I added a couple years ago that let the VecN types get constructed from anything that it has the same memory layout as a T[N] -- that should also allow transparent translation between different Imath ABI versions).

It seems like a nice idea to eliminate the version from the namespace entirely -- i.e. to have one and only one ABI for Imath forever after and simplify the whole situation. But that does mean that there isn't a graceful way to revise the ABI in the future, and it also means a full ABI break now, AGAIN (for some downstream users, that would even mean 3 ABIs they might encounter, because they are still dealing with 3.1 as well as 3.2.).

Keeping a version in the namespace lets is migrate in the future if we need to (hedging our bets), locking that version down rather than making it follow the project versioning at every bump makes it long-term stable (that's the main win we were going for), and starting with the current version we already have means we don't need to experience another break to make the switch to the new scheme.

So those are the pros of Kimball's current plan, as I understand it. The con is mainly that it's not quite as simple as just calling it "Imath" now and forever after. But "Imath" is the forever alias for whatever the current ABI is, so maybe what the users are directly exposed to already has the full dose of simplicity?

Switching to header-only is an orthogonal set of changes, though one I also support, since it removes another set of moving parts related to which version of the library gets linked.